Decisions

• QubitPairs cannot be permuted, i.e. QubitPair(q1, q2) != QubitPair(q2, q1)
• A QubitPair has a qubit_control and qubit_target
• GateImplementation.execute() takes positional arguments matching logical gate parameters (e.g. rotation_angle for Rx), whereas any keyword-only arguments can match pulse-level parameters (e.g. dc_offset, amplitude_scale).

Matching logical gates to gate implementations

The primary method of matching logical gates to gate implementations is by checking whether the qubit / qubit pair has a gate implementation whose name matches the logical gate.

If no match is found, an additional step can be performed for non-parametrized gates.
In this case, it checks if any of the gate implementations have a unitary representation matching that of the logical gate.
How to define a unitary representation still needs to be defined.
Note that defining a unitary representation of a gate implementation is optional.

Task list

• Rename Gate -> GateImplementation, e.g. SingleQubitGate -> SingleQubitGateImplementation
• Full test coverage
  • Macros
  • Qubit
  • QubitPair
  • Operation
• Fix Measure operation

Open questions

• Do we need to rename GateImplementation.execute()
• Do we need to rename GateImplementation.gates
• How to handle gate-level positional arguments which may have a different parameter order, or different parameter names, depending on the circuit-level language?
  • The order of logical unitaries is pretty standardized, our SDK should adopt this standard.
• How to match circuit-level gates to QUAM gate implementations?
• Should unitaries be added to GateImplementation?
• How to include non-gate operations, e.g. measure, align/barrier?
• How should pulses + channels be incorporated into gate implementations?
• How to handle qubit ordering conventions?
  • For example, Qiskit 2Q states |10> means that the control qubit it |0> and the target qubit is |1>